About two years ago, I wrote about moving to a Sandisk Sansa Fuze as my music player. I transitioned from a 40G, HDD-based iRiver to an 8G flash-based player, with an additional 32G supplied by a micro SD card, both running the rockbox open-source firmware. Of course, my music collection has grown over the last few years and so I needed to find another solution. That solution is another Sansa Fuze! This was actually my interim solution, this time with 4G internal capacity (didn't matter too much) with another 32G microsd and a rubber band. It turns out that managing four storage devices (two SDs and two embedded storages) is a complete nightmare. However, as luck would have it, I learned that the new, larger capacity SDXC cards can be made to work in some SD readers, including the Sansa Fuze. At around this time, my original player started to malfunction and so, another Sansa Fuze, again! It took three attempts to get a 64G microsd: the first was faulty or fake, the second never turned up. Third times a charm, and a third sansa fuze (to get 8G internal capacity) completes the story. For the sansa fuze, to get a 64G microsd to work, one needs to change the partition type to 0x0c (W95 FAT32 (LBA)) and reformat with FAT32. (Interestingly that's actually hard to do for Windows users, as Win 7 refuses to offer FAT32 for flash devices over 32G in capacity by default). I now have approximately 67.7G of storage on a single device and all my music in one place again (albeit two storage locations) which feels surprisingly good!

A big gap since the last Debian Day. On request I reviewed Gustavo Panizzo's Hexen 2 Package which is in pretty good shape and should be ready for upload fairly soon. A prerequisite for that is support for Hexen 2 in game-data-packager: I've hacked in preliminary support and pushed a package to experimental (version 31), it should be available not long after you read this. There's quite a lot more we could do with Hexen 2 support: rip the CD audio; encode it, there's an open question as to which codec to use, or to support multiple codecs; detect different versions of the game and re-order the CD tracks accordingly; support the mission pack; generalise any new ripping code so Quake support could use it; etc. etc.

Last year, via jwz, I watched the video "Archive Team: A distributed Preservation of Service Attack" from Defcon 19. I learned about the Archive Team and the work of Jason Scott. More recently I learned about the archive.org Shareware CD Archive. In the fledgling days of the Internet, shareware (and cover-mount) CD-ROMs were a popular way for files to be distributed. They therefore archive an interesting age in the history of modern Internet culture. Inspired by the above, I dug out some of my old shareware Doom CDs, ripped them, scanned their covers (where I had them) and uploaded them to archive.org. Here they are:

• The Ultimate Add-On Collection for Doom and Doom II
• D! 1000 (better CD scan needed)
• D! Zone Gold
• 3D Game Alchemy the CD that accompanied the book "3D Game Alchemy" (needs a better CD scan). I thought everyone had seen the stuff on this, but when Justin Fisher's NEMESIS.WAD appeared on Doomworld - relatively recently - I was surprised how few people were familiar with it.

They are all part of the growing Doom Level CD Collection. In most cases, the CDs are a super set of files that exist in the /idgames archive. I'm fairly sure there is some stuff on these CDs that never made out of BBSes or the AOL and CompuServe walled gardens onto the wider Internet, with the exception of these shovelware collections. A follow-on project would be to cross-reference their indexes with the /idgames archive and upload whats missing (that can be done so, legally.) Finally, I also had a single, solitary PC ZONE covermount CD that I held on to because it was a Quake (and Duke Nukem 3D) add-on special:

• CD Zone issue 48, March 1997

From an archive-perspective, Quake has not fared as well as Doom did. The Internet was young when Doom was popular, the World Wide Web was not the all-encompassing thing it has become and by accident rather than design nearly all Doom add-ons ended up being uploaded to a single FTP server: The Walnut Creek CDROM FTP Server, to a sub-folder /idgames. This single archive was mirrored wide and has lived on past the death of Walnut Creek. Today, it is small enough for casual enthusiasts to mirror, and has been kept alive by volunteer admins. The most popular front-end is now http://www.doomworld.com/idgames/. The WWW had grown up by the time Quake came along. There is an /idgames2, but it was never as popular as /idgames was for Doom. The Quake modding community was centered around a series of commercial websites such as Planet Quake, later part of the Gamespy network. Sadly the vast majority of web pages on the old Planet Quake site and similar sites have died completely from bit-rot. Large chunks of the history of the Quake community are therefore lost to a sort-of technological dark age.

Back in June or thereabouts I learned about a project to re-create Nine Inch Nails' first album "Pretty Hate Machine" as a chiptune cover/tribute project. This project is called Pretty Eight Machine. The artist InversePhase was kind enough to send me a copy of the CD as a random prize draw, so I thought I would write a few words about it. I don't know a great deal about the world of chiptunes, besides having heard a variety of "chiptune" covers of various well-known songs, some good, some bad. the backing track to this video, a cover of Tears for Fears' "Mad World", is, in my opinion, good. The front cover for P8M lovingly reflects the recent reworking of the classic PHM cover by Rob Sheridan, for the source album's recent deluxe reissue. There's a great in-depth interview with Rob about the process of reviving that cover at sleevage. That little homage is a good indication of the amount of effort and attention to detail that has gone into this project. One interesting thing about this project is that each track has been composed for a particular vintage chipset, such as the Commodore 64 in the case of the opening track "Head like I/O". InversePhase is very faithful to the original chips here, not just using their tones as part of a modern composition but constraining himself with the actual chipset limitations: for example, the number of voices that can be playing at once. (By contrast, that Tears for Fears chiptune above is the non-authentic type of chiptune). InversePhase tracks Trent's vocal lines as an instrument, so all of the notes that are heard in the original are present on this remake. It would be interesting to hear an "instrumental" mix of these tracks, and perhaps mix isolated vocal tracks from the originals on top My favourite track is probably "Kinda I Want To". I actually really like the original track, in particular the extended breakdown, where a synth noise gradually breaks down and disintegrates bar after bar. It suffered terribly from dated lyrics compared to other PHM tracks, but InversePhase's cover is saved that embarrassment. This particular track (apparently) makes use of a VCR6, a Konami chipset apparently used to supplement the hardware in the Famicom/NES. Yes, back then games came on cartidges that could supply bits of their own hardware if required. Those were the days! And yes InversePhase, you've successfully made the NES sound "dirty": and the synth breakdown sounds great. Any fan of the original album or anyone with an interest in what kind of noises vintage sound synthesis chipsets could produce are thoroughly recommended to give this album a try. You can preview all of the tracks and read per-track information on the bandcamp page.

Recently I have succumbed to a number of indie games sales, in particular ones in humble bundles, despite the fact I rarely play games these days. I might have been encouraged somewhat by a bad habit I've picked up: reading the excellent Rock Paper Shotgun, discovered via Stuart Campbell. I've got a back log of iPhone games to try out too, most of which I discovered via Stuart or his "Free App Hero" app. So, enough is enough: no more games until I've played my way through this list. I may add my iPhone games to that list and play with the ordering. If you can vouch for anything on the list or would suggest which are worth playing first, leave a comment!

What if you have a mis-behaving electronic device, which might corrupt files you store on it? I'm interested in tools to inspect incremental backups, look at file changes and alert me if they are suspicious. For example, if an MP3 changes, did the MPEG data change, or the ID3 tag, or something else? An ID3 change is likely to be on purpose, MPEG data less so. Similar for JPEGs and EXIF metadata. I decided to poke around in my backups of my music player. I discovered some pretty weird stuff. Firstly, quite a few MP3s seem to have changed on my player over time. I found 788 instances of MP3s changing a very small amount: an 11 byte rdiff-format patch. This seemed particularly strange, so I investigated a little:

...
01 Fool's Day.mp3.2012-05-31T22:40:09+01:00.diff
00000000  72 73 02 36 47 00 00 59  01 ad 00                  rs.6G..Y... 
0000000b
dark_entries.mp3.2012-05-31T22:40:09+01:00.diff
00000000  72 73 02 36 47 00 00 54  0f 58 00                  rs.6G..T.X. 
0000000b
...

In a nutshell, the patches appear to do nothing, or at least copy the input file verbatim into the output. (my rdifffs source is a useful document for the rdiff file format, or failing that, the rdiff source itself.) This is probably just a behavioural nuance of my backup software. That leaves 156 changed MP3s with rdiff patches ranging in size from 21 bytes to 26k. The smallest are almost certainly no-ops, just less efficiently stored ones. The largest looks like embedded album art in the ID3 tag being added, and I'm guessing the mid-size ones are ID3 textual changes (spelling corrections etc.), but ID3 changes are very hard to inspect by eye in the raw bytestream. For this reason I think a tool that could sort through file changes and pick out things which might need human investigation might be useful. Such tools could be run automatically after backups complete, or at scheduled times. I'll probably start writing some over the next few weeks, but if you know of any that already exist or might form part of a solution, please let me know!

I'm forty pages into a battered copy of "Complicity" by Iain Banks. I picked this copy up for the princely sum of 90p at Barter Books last weekend. For the uninitiated, Barter Books is a grand old bookshop situated in a disused train station in Alnwick, Northumberland. It has the dubious pleasure of being the originator of the "keep calm and carry on" fad. At the time that I bought it, I wasn't sure whether it was already in my swollen reading pile, but 90p wasn't a great loss if so. I could leave it in the book pile at my next hotel. (it was, and that's a sorry indictment of the state of my reading pile.) This gnarled paperback has character. There's a faded price sticker on the back revealing a first-hand price in Australian Dollars. The book started its post-sale life on the other side of the world. Where else has it been? I take some small pleasure in planning the next step in its future. To imagine this book with a long tail of readers having a free market value of 90p, or roughly the price of a posh chocolate bar, I'm struck by both wondering how publishers and writers like Mr Banks make a living (and yet they do) but also how the pricing of ebooks, completely lacking in this character I've written about and non-transferable, seems over inflated to the end user. I've been struggling to short list a selection of books to take on holiday. Most of my friends have responded "buy a kindle", with a complete lack of sympathy for my predicament. I'm borrowing one which means I can finally find out whether I'll "take" to it. I'm concerned I'll not be able to get sucked into a story in the same way I can with a paper book. I certainly won't rely on just the kindle for my reading needs. I don't want to prejudge my experiment too much but I suspect I won't be convinced. Where I can see technology supporting my reading is in addition to the paper book: particularly for non fiction, technical books, academic papers, more graphical-oriented things (photo books, graphic novels). I do have a small but growing collection of old, rare-in-print texts that I've only been able to source as PDFs. I think something like the Google Nexus 7 would do the job for these and fit into my life more readily than the kindle.

If you have an M-Audio Audiophile 24/96 PCI sound card or anything else using the "Envy24" chip, be aware: at present neither the GNOME3 "sound" control panel applet nor the pulseaudio tool "pavucontrol" expose enough of the card's controls to play any audio. You need to have alsa-utils or alsa-tools-gui installed and use envy24control to put the relevant sliders in the right places.

I recently discovered the excellent BBC 6 Music: a digital-only radio station so good I'm almost convinced to buy a DAB radio for this one station alone. In particular, Stuart Maconie and Mark Radcliffe, former Radio 2 exiles, hold an excellent afternoon slot. Stuart Maconie's late-night "Freak Zone" often has some really interesting stuff on it worth listening to, for example an entire episode dedicated to Brian Eno's "Obscure Records" label. Ubuweb recently put up the entire catalogue, by the way. @WhatsOn6Music is a twitter bot I follow which tweets songs as they are played. This works because most of the BBC's DJ consoles are wired up to last.fm. In recent times this bot has been broken a lot, so I got tired of it and made my own: @6musicbot. This one is powered by IFTTT so should not be plagued by whatever keeps breaking the other one: although it's also only as good as the last.fm feed powering it. Let me know if you find it useful, interesting or have any other feedback.

Once again Debian day was somewhat compromised: this time by more DIY. I still managed a few bits and pieces, amortized over the rest of the week. I benefited from some train time this weekend. A new version of flactag and catching up the flactag packaging vcs repository. A maintainer endorsement for one of the flactag maintainers and a request to NM for another maintainer to be granted access to the collab-maint repository. More work on the musicbrainz 'transition': First, usertag tracking of packages to update, with upstream bugs where necessary. Tested and confirmed Michael Biebl's sushi patch; found and fixed a sushi bug along the way; wrote patches for sound-juicer ( merged upstream) and goobox.

And we've frozen! How have we done on the musicbrainz stuff? I was really pleased to see Michael Biebl upload new sound-juicer (four bugs closed!), rhythmbox and gnome-sushi packages which move them up to musicbrainz5. I NMUed goobox (with the maintainer's permission) but sadly there was a build issue and the NMU was reversed with a second upload, so it's back to using libmusicbrainz3 in the freeze. that leaves two more packages. I haven't discussed or considered putting forward this 'transition' for freeze exceptions, but Pino Toscano raised a good point: upstream might not support the version 1 WS API (which libmusicbrainz3 depends on) throughout the wheezy lifetime. Some more research here is needed. What else? NMU of acpidump to resolve a trivial manpage error that I filed a patch for two years ago; the latest flactag upstream version; a new version of game-data-packager, incorporating stuff Joey Schmit patched last year, which fixes Heretic support and adds Hexen support; a new version of chocolate-doom. The last two are particularly interesting because I'm in Uploaders: despite having left the Games team last year: there have been no subsequent uploads before my latest ones. I removed myself from Uploaders: with these uploads, which technically means they are NMUs. What next? Typically I find the freeze time a hard one to work on Debian. I've never been very effective at chasing and resolving RC bugs. On the other hand, long, protracted freezes are demotivational for everyone. I'm going to try and focus on goals which hasten the release of wheezy and resist the urge to work on things that would not show up until wheezy+1.

Very little done last night. Advocated a maintainer. My desktop computer is completely hosed as part of a wheezy update: many issues at once but one is GDM going into an infinite loop, spawning millions of X servers; another is something in the boot processes seemingly prodding /dev/sdc and failing. I'm not sure if I have time to get to the bottom of it, I might just reinstall from a d-i daily. Priority going forward should be to finish off the musicbrainz stuff. Pleased to see my gnome sushi patch merged upstream.

This blog has been cited in an academic paper! On October 2011 I drafted a blog post about Infosuicide, or "Infocide" as I prefer, prompted by Mark Pilgrim's disappearance. I never got around to finishing the post up in particular I felt it was too long but my draft was exposed to the Internet and somebody noticed it. Assistant Professor Joseph Reagle stumbled across my draft and wrote an in-depth paper 410 Gone : Infocide in Open Content Communities citing a whole load of writings on the subject, including my own. I believe his paper has now been submitted to a conference proceedings (I'll update this when I find out which!) For that reason I've gone ahead and published the draft as-is.

Once again Debian day was somewhat compromised: this time by more DIY. I still managed a few bits and pieces, amortized over the rest of the week. I benefited from some train time this weekend. A new version of flactag and catching up the flactag packaging vcs repository. A maintainer endorsement for one of the flactag maintainers and a request to NM for another maintainer to be granted access to the collab-maint repository. More work on the musicbrainz 'transition': First, usertag tracking of packages to update, with upstream bugs where necessary. Tested and confirmed Michael Biebl's sushi patch; found and fixed a sushi bug along the way; wrote patches for sound-juicer ( merged upstream) and goobox.

One interesting side-effect of setting aside a regular slot of time for a task is that you are guaranteed to spend some time, perhaps not much, thinking about that task, every week. As a consequence, even one evening a week is enough for me to think about my Debian work at other times. This means I am in a better position to use any unplanned free time more effectively. This Tuesday was a bank holiday which I spent on DIY, lounging in a chocolate shop and catching up on The Apprentice, so there wasn't a 'Debian Day' per se. However, I did upload a few versions of lhasa. Following on from last week's thoughts on sound-juicer, I'm pleased to report that the two folks working on a more recent musicbrainz update were in fact working together, and after some discussion Michael Biebl sponsored an upload. Thanks Michael! Once that had gone in I was free to sponsor flactag, which was packaged by the same folks. There's some follow-on work to do for musicbrainz5. In Debian, gnome-mplayer, gnome-sushi, goobox, kdemultimedia, rhythmbox and sound-juicer need updating; I'm fairly sure Michael sorted out a patch for gnome-sushi at least but upstream want a patch that implements falling back to version 4 if version 5 doesn't exist. Finally, I sponsored Gustavo's vavoom package.

After a relatively long period of flux, I've managed to settle into a routine where I've got all the time I can dedicate to open source stuff bunched together: every Tuesday night. I've started calling it "Debian Day", although Debian won't get all that time exclusively. One evening a week doesn't sound like much, but that's unfortunately a realistic amount given my other commitments. Still, having a firm idea of how much resource I have makes planning what I can and can't do much easier. It also means I need to be quite selective about what I spend my time on. This also impacts the type of interactions I can use. I can respond to email, bugs, etc., but I cannot effectively interact with folks on IRC, for example: the period between windows is too large for it to work effectively. Therefore, I can't work reliably with any team or area of Debian that relies on IRC to get things done. Tonight, then. I have recently been ripping some CDs, a task for which I use grip, despite it long since having been dropped by Debian. It still works very well, whereas Sound Juicer, which still pops up whenever I insert an audio CD, does not. I've been interested in helping out with Debian GNOME packaging for a while, and it seems the issue has been fixed upstream, but after asking around in #debian-gnome, the root cause is that the newer musicbrainz API packages have not been uploaded to Debian. (the existing package uses the old API). Two separate people appear to have been working on a new Music Brainz package, but neither filed an ITP bug. I've spent the largest chunk of my Debian time just trying to figure out what has been going on, sadly, but at least there's the likelyhood this will be fixed for wheezy. There's also the tail end of a musicbrainz-2.1 transition finishing up. Another thing I considered this evening was the future of debgtd in Debian stable. On reflection, and after sitting on the fence for several months, I've decided I don't have the time to fix it up enough to have it ready for wheezy, so with regret I've filed a removal bug. With any luck, at some point in the wheezy cycle I'll manage to put more time towards this, because I think it addresses a genuine need and could be useful to people. Finally, whenever I sit down and look at Debian stuff to finish up, I have a strong temptation to fix some issues belonging to the games team. In particular, Gustavo Panizzo has put a lot of work into vavoom packages, but sadly his requests for sponsorship are falling on deaf ears. There's also Johey Shmit's work on packaging zdoom which needs some attention to finish removing some embedded libraries. I have to keep reminding myself I left the team for a reason, to focus on something else, and finding that something else should be the priority. So all in all not the most uplifting evening: I'm starting to think I simply couldn't work effectively with the Debian GNOME team without being able to dedicate more time to use IRC effectively; I spent more time that could be necessary figuring out a bunch of other folks have potentially wasted each other's time by working on packages and not filing ITPs; and I've removed one of my own packages from the distribution altogether. It's not all doom and gloom, though: last week I packaged Simon Howard's lhasa, a library and tool for decompressing LHA files, as used by various old DOS games. (See? I just can't escape that stuff ) I also managed to 'resolve' two bup bugs, one RC. I also finished transitioning from my old PGP key to my new one.

I've just read and enjoyed this post by Mike Abrash about working at Valve. I enjoyed it for two reasons: firstly, doom played a pivotal role in shaping Abrash's thinking about the future of computing, or perhaps it shaped the future of computing itself. I'm not ashamed to admit that Doom played a pivotal role in making me the person I am today: it derailed my ambition to become a graphics designer, introduced me to the PC, programming and various other computer design technologies and concepts: things moved on from there. The second reason is the culture that Abrash describes at Valve: flat, creative-driven, unafraid of failure. I've been thinking a lot about work environments and the nature of management, both in the context of my work and Debian. What Abrash describes is still vastly different to life at University, but it did force me to reflect on how lucky I am to have the freedom and conditions I have, and consider the ways in which I define and shape the environment for myself and others.

In (roughly) 2008 I read "Blood Music" my first Greg Bear novel and devoured it in a weekend, in only two or three reading sessions. That happens very rarely, and when it does I often wonder whether it's the quality of the writing or some combination of that and your personal moods and tastes at the time that is responsible. My next Bear was "Darwin's Radio" in mid-2010 which, whilst good, did not provoke the same feverish read. I might write short reviews for both at some point in the future, but right now I can't remember either well enough to do so. In the last few weeks I read "Hull Zero Three" which was quite a different beast. The novel first captured my attention due to the unusual way it was promoted: via a video, which was created using a modified Quake 2 engine. It wasn't a great video but the novelty made it interesting. The story begins with a first-person narrator waking up from a sort-of hyper sleep on a generation starship that has clearly had some serious problems. He has to run to escape danger before he has an opportunity to figure out exactly what has happened and what he is running from, or to. Something has gone horribly wrong on the ship: it's nowhere near where it should be going and nobody should be awake. The narrator's memory is fractured, fabricated and unreliable; the ship is hostile, and whilst it's mechanical, it cyclically changes and re-arranges it's hulls in an almost organic way. He is joined by a rotating cast of similarly confused refugees of varying shapes and sizes. Language and cultural barriers serve to further magnify the sense of alienation that you experience on behalf of the story teller. The troupe are persued through the corridors by a collection of lethally efficient killer "things", contrasting with the background by being organic in nature but mechanical in behaviour and appearance. The scale of the ship is necessarily massive, and Bear does an impressive job of capturing the awe you might feel when considering it. Three huge, cigar-shaped hulls, joined by "spars" to an enormous chunk of ice captured from the Oort cloud on exodus from the solar system. The ice serves as a mixture of "fuel" for the biological ship systems and as part of a shield system for the hulls from cosmic rays. However, in part due to the narrator's confusion, it was hard to follow the very abstract descriptions of the environment in the earlier stages of the story. I found myself re-reading passages to try and understand the comparisons being offered and scales presented. In common with the two earlier Bears I've read, 'body horror' features prominently in this story. It feels like a "Dead Space" or "Resident Evil" in space in a hard SF novel which seriously attempt to capture real speculative science. Like "Blood Music", I found myself compelled to read "Hull Zero Three" at every available opportunity. I finished it off in a very enjoyable reading session outdoors in the spring sunshine. It was an enjoyable read, well written but not beyond criticism, with some interesting takes on well-worn themes. Very reminiscent of the movie "Pandorum" (which was a surprisingly good movie).